We have a 2012 R2 DirectAccess implementation that seems to work well. However, one thing continues to be a problem. While connected remotely via DA, Outlook 2013 seems to "hang" whenever you delete a message or close an email that is open and shows "not responding" on the title bar. After 20 seconds or so, Outlook will come back and keep working. This only happens on DirectAccess clients, and not with internal Outlook clients or Outlook Anywhere external clients. It has become such an annoyance that my users are asking to be removed from DirectAccess so that they can just use VPN and not deal with the Outlook "hang".

I cannot find anything that points to this type of issue or what might be happening. Anyone else seen this?

Doug

One thing that I should clarify... The "hang" occurs after you hit the "send" button. Not delete or close. The message that you are sending closes quickly, but the main Outlook window hangs for 15-20 seconds before coming back.

Hi,

I never had problems with Outlook (2010 and 2013) on a DirectAccess computer.
The issue is probably caused by a wrong configuration of the mail client.

What kind of mail system are you using?

Gerald

Doug,

If DirectAcces is configured with split-tunneling mode and you are connecting to an internal Exchange Organization; it is a best-practice to bypass DirectAccess to connect to your Exchange CAS (Client Access Services). Same thing for Lync/Skype for Business. This will make sure the configuration is simplified and Exchange is still available when DirectAccess connectivity is unavailable. Of course your CAS should be available (published) from the internet.

To let it bypass DirectAccess you have to configure the NRPT from DirectAccess in such a way that Exchange related hostnames (FQDN's) are excluded.

If you don't want Exchange traffic to bypass DirectAccess, then you have to make sure each Exchange related hostname is a FQDN, resolvable and routed through DirectAccess. You probably did, but just double-check it. Also check you are not using SRV records from another Domain Namespace that redirects to your autodiscover FQDN.

Yes, we are bypassing DA for the Exchange CAS. I think that I have found a potential cause. After reading the following article:

https://support.microsoft.com/en-us/kb/2652320

I focused on outlook addins, and found one that seems to be the culprit. This addin is loaded on all corporate machines, so I am doing some testing to confirm, but so far, it looks like the problem.

Doug

Yes, we are bypassing DA for the Exchange CAS. I think that I have found a potential cause. After reading the following article:

https://support.microsoft.com/en-us/kb/2652320

I focused on outlook addins, and found one that seems to be the culprit. This addin is loaded on all corporate machines, so I am doing some testing to confirm, but so far, it looks like the problem.

Doug

• Marked as answer by SnoopD 17 hours 5 minutes ago

Yes, we are bypassing DA for the Exchange CAS. I think that I have found a potential cause. After reading the following article:

https://support.microsoft.com/en-us/kb/2652320

I focused on outlook addins, and found one that seems to be the culprit. This addin is loaded on all corporate machines, so I am doing some testing to confirm, but so far, it looks like the problem.

Doug

• Marked as answer by SnoopD Tuesday, June 09, 2015 2:19 PM

Yes, we are bypassing DA for the Exchange CAS. I think that I have found a potential cause. After reading the following article:

https://support.microsoft.com/en-us/kb/2652320

I focused on outlook addins, and found one that seems to be the culprit. This addin is loaded on all corporate machines, so I am doing some testing to confirm, but so far, it looks like the problem.

Doug

• Marked as answer by SnoopD Tuesday, June 09, 2015 2:19 PM